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REMARKS 

Entry of the amendment, reconsideration, and allowance of the subject application are 
respectfully requested. 

Claim 2 stands rejected under 35 USC §112, first paragraph for indefiniteness. This 
rejection is respectfully traversed. 

The Examiner alleges that claim 2 is a "single means" claim. This is not the case. In 
contrast to the In re Hyatt case where there was in fact a claim with a single means recitation, the 
word "means" is not used. So claim 2 is not a means claim. Nor does the computer, recited in 
claim 2 cover every conceivable means for achieving a single property or single result. The 
computer is configured to perform multiple different functions and multiple different sub- 
functions. In other words, multiple different properties are involved. Given the recitation of 
multiple functions, claim 2 does not cover every conceivable means or structure for achieving a 
single function. 

Claims 1 and 3 stand rejected under 35 USC §112, second paragraph for indefiniteness. 
I Lis rejection is respectfully traversed. 

For claim 1 , the Examiner asks whether the clearing and settlement processes are 
implemented by the same computer or two computers. The claim is not limited to a particular 
computer configuration. Rather, it may implemented using one computer, two computers, or 
more than two computers. To address the Examiner's concern, this claim is amended to remove 
references to "a computer" and inserts the term "computer-implemented." 

As to claim 3, the Examiner is unclear of the relationship between the clearing and 
settlement computers. The settlement computer includes means that operate on information 
generated by means in the clearing computer. Thus, it is clear that the computers are arranged to 
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communicate with each other. To make this even more clear, claim 3 is amended to recite "a 
settlement computer arranged for communication with the clearing computer." 

Withdrawal of the rejections under 35 USC §112, first and second paragraphs is 
requested. 

Claims 1-3 stand rejected under 35 USC §103 as being unpatentable over newly-applied 
Hawkins, This rejection is respectfully traversed. 

Hawkins describes, an OTC trade confirmation system, with the purpose of certifying 
that both trading parties 30, 40 engaging in a trade can confirm the properties of the trade before 
it is executed. This is managed by a CMS server 35 that allows brokers to enter trades into the 
system, The system then allows both parties to confirm the properties of the trade after which, if 
no customized delivery instructions were entered with the trade orders, the transaction is 
completed with standard delivery instructions of the brokers received from a standing delivery 
instructions database. The CMS server then relays the trades to the different clearing agents of 
the brokers (Figures 5 and 7 and col. 14, line 64- col. 1 5, line 1). Thus, Hawkins improves the 
processing before submitting settlement instructions to the investor's clearing agent (see col, 7, 
lines 53-64: "automatically matches an investor's security order with an executing broker's 
confirmation and automatically generates and routes via a network , such as . . .(SWIFT) 
Financial Network, a settlement instruction to the investor's clearing agent"). That SWIFT 
messages are used in this process (see also col. 8, lines 13-47) is just a further confirmation that 
Hawkins describes an Electronic Trade Confirmation system that operates before settlement. 
The standing delivery instructions (or customized delivery instructions per each order, col, 14, 
line 66 - col. 15, line 1) allow the originating broker's and the executing broker's clearing agents 
to settle the trade (col. 14, lines 64-66) but are not a part of the settlement process, 
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In the pending claims, trades are cleared and settled within a Central-Securities- 
Depository (CSD) system in a more generalized and flexible manner than previously possible. 
By adding the automatic functions of defining a settlement obligation group, selecting one or 
more settlement rules, and locking-in of assets to the clearing process, the settlement process 
within a CSD can be simplified into a generally-applicable settlement process, where irrevocable 
transfer instructions are selected for all settlement obligations belonging to the settlement 
obligation groups followed by verification and reporting steps. 

The Examiner states that "Hawkins discloses an automated computer-implemented 
method and system for carrying out financial transactions within a Central Securities Depository 
(CSD), the method comprising an automated clearing process implemented by a computer and an 
automated settlement process implemented by a computer." Applicants respectfully disagree. 
The financial transactions carried out by Hawkins are not carried out within a Central Securities 
Depository . Rather, Hawkins describes an OTC (Over-the-Counter) trade match and 
management system mainly intended for brokers. What Hawkins describes is performed before 
a CSD is involved in the transaction chain. Applicants request that the Examiner specifically 
identify what structure in Hawkins corresponds to a CSD and where Hawkins describes 
the claimed operations being performed in a CSD. 

The Examiner argues that Hawkins describes "the clearing process preparing transaction 
for the settlement process, using the following automated sub-process steps implemented by a 
computer: selecting a settlement rule to be followed in the clearing process, the rule defining 
how the transaction is to be settled." The Examiner suggests that "matching transactions 
automatically results in the selecting a settlement rule." Applicants disagree. 
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Figure 7 and Figure 30 describe a system matching transactions. The transactions are 
provided to the clearing agents with settlement instructions either provided as standing delivery 
instructions or as customized settlement delivery instructions for each order. Hawkins thus 
describes completing a newly-matched transaction using the participant's pre-defined or 
customized settlement conditions. For example, if a broker matches a trade for a certain equity, 
the broker might want the match to be settled with the clearing agent, Merill Lynch NY branch, 
account number 12345, etc. 

The claimed settlement rule does not complete the transaction using simple settlement 
delivery instructions, as does the CMS system of Hawkins, but rather defines within a CSD "how 
the transaction is to be settled," i.e., which settlement instructions/conditions should be processed 
together and by what routine they should settled. A non-limiting example settlement rule may 
determine that within the settlement process, equity transactions should be netted together while 
bond transactions settle gross. 

Accordingly, the delivery instructions of Hawkins are not the same as the claimed 
settlement rules, and the claimed selection of the settlement rule is not the same as providing the 
clearing agents with a matched transaction including a corresponding delivery instruction, 
customized by a broker on per trade basis or selected from a server containing standing delivery 
instructions based on broker ID (see col. 14, lines 59-63). Even if one assumed that a delivery 
instruction corresponds to a settlement rule, No other selection after matching can be found in 
Hawkins. The Examiner's conclusion that "matching transactions automatically results in the 
selecting a settlement rule" is in error. 

In contending that "netting and block confirmations imply a settlement obligation group," 
but the Examiner reads too much into the block confirmations in Hawkins (col. 11, lines 51-67) 
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as to block-wise confirmation from the executing broker to the instructing/initiating broker of a 
trade issuing a block trade. This simply relates to a group of trades to be matched. It is not the 
same as "a settlement obligation group including a number of settlement instructions to be settled 
at the same time ." 

To simplify and explain further, an example is provided. If a first broker represents 
several clients wanting to sell a total of 2 million shares of a certain stock, the first broker might 
directly enter a block order (an allocation of a block trade) representing all the different trades 
relating to his different clients into the CMS server in an effort to find a buyer for the shares, or 
he might by some other form of contact strike a deal with a second executing broker and after 
that enter the same allocation of block trades into the CMS server. The executing broker 
downloads the allocation from the CMS server, and if he agrees with the entered block trade 
allocation, he sends a confirmation message to the CMS server confirming the block of trades, 
i.e., the executing broker sends a block confirmation. Support for this example can be found in 
Figure 2d and col, 1 1 , lines 51-67 of Hawkins. So it is clear that a block of trades is not a group 
of a settlement instructions to be settled at the same time as claimed. 

Regarding the use of SWIFT to relay pre-settlement trade messages, see: 
\ v : -; " / • :cs.-; .;re-i :-v,;a»-mes/post trade _ pre se ttlement/trade co 

. {is . At col. 1 1, lines 51-67, Hawkins describes how the brokers using the 

CMS system and SWIFT and SWIFT ETC messages (col. 8, lines 13-47) can confirm blocks of 
transactions and, after completing them with standing delivery instructions or with order- 
customized delivery instructions, forward them to their Clearing Agents (Figures 5 and 7 and col. 
14, lines 64- col. 1 5, line 1). These transaction blocks include trades that the broker thinks are 
related and have nothing to do with the claimed settlement obligation group defined and formed 
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within the clearing process of a CSD. The claimed settlement obligations group is a collection of 
settlement obligations that are held together to be locked-in/cleared and settled, e.g., "all or 
nothing." This group is determined from a market perspective and processing perspective and 
has nothing to do with the broker's grouping of trades into blocks or the confirmation of those 
blocks. 

The Examiner next argues that Hawkins describes "locking in of the assets to which the 
transaction concerns, the locking-in having the effect of reserving said assets for a specific 
settlement," referring to col. 27, lines 25-34, and then concludes that "safekeeping is interpreted 
to include this feature." Applicants respectfully disagree. Safekeeping is a general term for 
book entry accounting in electronic registries of securities ownership. But within a CSD system , 
a custodian may manage one or several safekeeping accounts on behalf of investors directly or 
indirectly through the investors' brokers. In claim 1, when a settlement obligation group is going 
to be settled in the CSD system, "locking-in" is a clearing step where assets of cash and 
securities are reserved in preparation for final settlement. All settlement obligations within a 
settlement obligation group must successfully be locked-in before a final settlement execution 
can proceed, Securities that are in safekeeping will likewise be reserved in the locking-in 
process, still remaining in the original account until all is clear to transfer. Hawkins mention of 
safekeeping in the glossary and Figures 29 and 30 does not describe the claimed clearing step 
within a CSD of locking-in assets in a safekeeping account to reserve those assets for a specific 
settlement . 

The Examiner further states that Hawkins describes a settlement process that "includes 
the following automated sub-process implemented by a computer: selecting transfer instructions 
for all settlement obligations belonging to said settlement obligation group, said transfer 
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instructions being irrevocable instructions to transfer the locked-in assets between participants in 
the CSD" and opines that "netting and block confirmations" includes these features. This is not 
the case. Block confirmations, discussed above, do not contain any of the elements of the 
claimed settlement process. Further, the CMS system is not an automated settlement process 
where irrevocable transfer instructions are selected for all settlement obligations belonging to a 
certain settlement obligation group (also described above) or that these transfer instructions 
pertain to "locked-in" assets. 

Regarding the settlement process, the Examiner asserts that Hawkins describes "checking 
that said transfer instructions are carried out successfully" and also that Hawkins describes 
"reporting the results of the settlement to the participants involved." Applicants disagree. The 
report function of Hawkins (col. 21, lines 25-36) displays current trades at the broker's screen. 
The trade summary function prints a report of all the "confirmations" that are currently displayed 
in the trade summary. Hawkins describes how a user/broker can enter into a trade history dialog 
box corresponding either to the history of the confirmations stored locally or the history of trades 
downloaded from the CMS server. Thus, the reported results are confirmations of matched 
trades -- not reports of the settlement or the success of the actual delivery, i.e., the transfer 
between safekeeping accounts of a CSD. 

Because the claim features of defining settlement obligation groups, selecting settlement 
rules, and "locking-in" are not taught by Hawkins, and given that the new combination of these 
features and their inclusion in the clearing process of a CSD makes it possible to simplify and the 
settlement process of a CSD is not even hinted by Hawkins, it would not have been obvious for a 
person skilled in the art, at the time the application was filed, to arrive at claims 1-3. 
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The application is in condition for allowance. An early notice to that effect is earnestly 
solicited. 

Respectfully submitted, 



NIXON & VANDERHYE P.C. 




Reg. No. 33,149 

JRL:maa 

901 North Glebe Road, 1 1th Floor 
Arlington, VA 22203-1808 
Telephone: (703) 816-4000 
Facsimile: (703) 816-4100 
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